Conceptual Foundations for a Model of Task-based Authorizations

ion and Composition One of the rst issues that arises is that of abstraction and modeling. What is the proper abstraction to specify and manage authorization functions and tasks. We propose the abstraction of an authorization-task-unit to model the authorizations associated with every authorization function. Such an authorization unit may be composed of other smaller units called called approval-steps (this is analogous to the composition of functions). These smaller units map to the individual approval steps required to complete the processing of an authorization function. Dependencies Any model of authorizations must have the expressive power to model the dependencies between authorization-units as well as those internal to an authorization unit. These dependencies arise due to the structural and semantic properties of the responsibilities and activities in the enterprise. There exists various kinds of dependencies. Some of these are identi ed below. { Temporal Here we are concerned with dependencies that constrain the temporal order of the execution of authorizations. Consider an application that requires three approvals (signatures) S1; S2; S3. Organizational policy may require the following dependencies to be enforced: (a) S2 cannot be granted until S1 has been granted; (b) S3 cannot be granted until both S2 and S3 have been granted. In our sales processing application, the sales-order is allowed to progress only after the credit manager in the credit department signs o on the order. It is clear that we have to address issues related to both the speci cation and enforcement of dependencies. { Semantic Here we are interested in dependencies that arise from the semantics of the application. For example, seeking authorization to transfer funds between two accounts may semantically imply the need for authorizations to withdraw from the source account as well as deposit in the target account. How can such a semantic unit be expressed and managed? { Atomic We may require the granting of a certain group of authorizations to be atomic. In other words, if one of the authorizations in a group is not granted, we may wish that others in the group to be not granted as well since we want the system to be una ected by the entire group. The atomicity requirement may directly follow from the semantics of the application, 11 and its implementation may require interactions with revocation mechanisms. Is there an analog to the atomic transaction in the realm of authorizations? One could think of the abstraction of an atomic-authorizationtask-unit that guarantees atomicity of authorizations internal to it. Incorporation of controls What are the proper constructs and mechanisms needed to specify and enforce internal controls such as separation of duties, multiple approvals, and rotation of assignments? A general model must support such controls both within, as well as across, authorization-task-units. Delegation and revocation In our sales-processing example, the vendor organization might upgrade the credit rating required of its customers, and as a result, the credit authorization on a sales order may be revoked if a customer fails to meet this new cuto . In other words, the credit manager is now no longer willing to take responsibility for such a customer. Examples of this call for appropriate delegation and revocation mechanisms. Authorization expirations In the paper world, a signature on a form has validity only for a certain period. In other words, the authorization has an expiration date. If an authorization expires, the related activities may have to be cancelled, and other authorizations whose validity is conditional on the expired authorization, may have to be revoked. We are thus faced with issues related to the modeling and implementation of expirations. Authorization deadlines There exists scenarios in organizations where an authorization may have to be obtained within a deadline. For example, a manager responsible for giving approvals may be available only for certain hours during the week, or may be going on vacation for the next two weeks. In this case, we may want to associate deadlines for the obtaining of authorizations so as to meet customer needs in time. Such deadlines will in turn directly impact the scheduling priorities of authorization-tasks. Failure and Exception handling If a certain authorization is not forthcoming, how do we specify alternate authorizations? Also how do we specify exceptions to general policy? For example, a new customer may not have any established credit and the organizational policy may call for the approval of the customer's sales order so long as it does not exceed a certain amount. Another example is when a manager is unavailable, and we wish to specify that someone else be allowed to authorize on the manager's behalf. 12 Deadlocked authorizations Is it possible for authorization-tasks to become deadlocked? If this happens, does it imply that there is something wrong with the authorization and responsibility structures of the organization? The above list is not meant to be a complete one, but rather to be indicative of the complexity involved in formulating and implementing a model. It should also be clear that some of the issues listed are related to speci cation and modeling, while others (such as deadlocks) are related to implementation. In comparing the above list to transaction control expressions (TCE's) [15, 16] and Badger's model [3], we see that they provide support to express limited dependencies. Thus TCE's can express only linear dependencies while Badger's model can express nested (hierarchical) structures. TCE's also provide separation of duties only within individual transient objects. It is not clear how Badger's model can be linked to enterprise level requirements and policies. Neither of these models provide constructs to express authorization deadlines and expirations. 4 Groundwork for Building a Model In this section we develop the basic building blocks required to construct a model of task-based authorizations. Our purpose is not to introduce a formal model (or the machinery for this) as doing so would be premature at this point. It is also important to bear in mind that we are not describing mechanisms (the how), rather the concepts (the what) for which mechanisms would have to built later. 4.1 Basic Modeling Constructs The basic modeling constructs in our model are listed below. An application is built using authorization-task-units which in turn are composed of individual approvalsteps. The various task-units and approval-steps in an application are related to each other through dependency speci cations. Authorization-task-unit(task-name): Each authorization task contains the following elds: { Originating-function:function-name { Attributes: Atomic, Expiration, Deadline { Dependency Speci cations:f g { Approval-steps:f g 13 .. .. Temporal-dependency Authorization/approval T2 cannot be granted until T1 has been successfully granted Failure-dependency T1 T2 Separation-with-rolesubstitution Behavioral : Structural : Atomic-auth-task-unit Auth-task-unit